[#12453] improvement(core): add OCC for schema writes - #12456

### What changes were proposed in this pull request?

Add database-backed optimistic concurrency control and transaction
boundaries for catalog writes.

- Advance the catalog OCC version on every alter and on an overwrite
insert, and guard alter and drop with a compare-and-set on the observed
version, classifying a failed CAS as either a stale-version conflict or
an already-missing entity.
- Protect catalog creation with a shared lock on the parent metalake row
on MySQL and PostgreSQL, without changing the parent version. H2 uses an
exclusive lock because it has no shared row-lock syntax, so catalog
creations under one metalake serialize on H2.
- Keep the catalog CAS and the non-empty check or the cascade cleanup in
one database transaction, and CAS-delete descendant schemas with their
observed identifier-and-version pairs.
- Keep the drop idempotent when another server deletes the catalog
mid-request: a later store read such as listing schemas reports the
catalog as missing, and the cached catalog wrapper is discarded.
(`store.delete` maps a missing entity to `false` on its own.)
- Comment the concurrency-critical statements, so the reason for their
ordering is readable next to the code.

Rebased on current `main` (on top of #12374). Second of three PRs
replacing #12350.

**Known window:** until #12456 lands, a schema created concurrently with
a catalog drop can still slip through, because schema writes do not yet
take the parent catalog row lock. #12456 adds that lock, which closes
the window for both the cascade cleanup and the non-empty check.

### Why are the changes needed?

Managed catalog operations previously consisted of multiple independent
reads and writes. Concurrent alter, create, and drop requests could
overwrite newer metadata, create a catalog below a metalake that was
being deleted, or run partial cascade cleanup.

Fix: #12452

### Does this PR introduce _any_ user-facing change?

Concurrent catalog version conflicts are reported as HTTP 409. If the
observed entity was deleted or renamed away, alter reports not found and
drop preserves its idempotent false result.

### How was this patch tested?

- `./gradlew :core:test :core:javadoc -PskipITs` (H2)
- New tests in `TestCatalogMetaService`, `TestCatalogManager`,
`TestPOConverters`, including
`testOverwriteInsertAdvancesCurrentVersion`, which checks that an
overwrite moves the version forward and that a writer holding the
pre-overwrite version no longer passes its CAS.
- MySQL and PostgreSQL coverage is left to CI
(`-PskipDockerTests=false`).

---------

Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

### What changes were proposed in this pull request?

- Use `current_version` as the OCC token for table alter and direct
delete.
- Execute the root table CAS before version, column, and dependent-row
writes in one transaction.
- Distinguish a concurrent version change from a deleted, renamed, or
moved table.
- Let optimistic-lock conflicts reach the caller on the managed paths,
which write to the store directly. The best-effort
`OperationDispatcher.operateOnEntity` helper keeps swallowing them: only
external entities reach it, and there the catalog was already changed,
so failing would invite a retry that re-applies a non-idempotent change.
- Retry only optimistic-lock conflicts for idempotent Lance metadata
repair.
- Add comments explaining the transaction ordering, CAS predicates,
conflict classification, and retry behavior.
- Add comprehensive unit and cross-database tests.

This PR depends on #12456.

Two things are deliberately left out. The conflict classification
(`tableWriteFailure`) and the locking select now exist once per entity
type; extracting them is a follow-up once the series is done, because
what differs per entity is the mapper, which identity columns to
compare, and schema's physical-to-logical conversion, so doing it now
means refactoring three merged services from inside a fourth. And a
version conflict while dropping is tracked in #12597, which covers every
entity type rather than this path alone.

### Why are the changes needed?

Concurrent table writes could overwrite the winning version metadata,
while a stale delete could remove data belonging to a newer table
version. Some optimistic-lock conflicts were also swallowed or treated
as generic IO failures.

Fix: #12345

### Does this PR introduce _any_ user-facing change?

Stale managed-table writes now fail with the existing optimistic-lock
conflict response instead of silently overwriting newer metadata. Reads
and the import path are unchanged: loading an entity still repairs the
Gravitino copy on a best-effort basis, so a load that loses a version
race keeps returning the entity. No API or property is added.

### How was this patch tested?

- Ran 48 `TableMetaService` cases across H2, MySQL, and PostgreSQL.
- Ran all 16 `TestTableOperationDispatcher` tests.
- Ran 4 SQL provider OCC tests.
- Ran 27 Lance table and concurrent-repair tests.
- Ran Spotless and `git diff --check`.